The present invention relates generally to techniques for developing and delivering virtual machine implementations. More specifically, the invention relates to techniques for creating virtual machine implementations that may be exchanged without requiring modification of the supporting libraries.
The Java(trademark) programming language is an object-based high level programming language developed by Sun Microsystems, Inc. of Palo Alto, Calif., and is designed to be portable enough to be executed on a wide range of computers ranging from small devices (e.g., pagers, cell phones and smart cards) up to supercomputers. Computer programs written in the Java programming language (and other languages) may be compiled into Java virtual machine instructions for execution by a Java virtual machine implementation. In the abstract, a virtual machine interprets virtual machine instructions. That is, the virtual machine decodes and executes the virtual machine instructions. Thus, the Java virtual machine interprets Java virtual machine instructions.
The Java virtual machine is commonly implemented in software by means of an interpreter for the Java virtual machine instruction set, but in general may be software, hardware, or both. Conventional virtual machine interpreters decode and execute the virtual machine instructions of an interpreted program one instruction at a time during execution, e.g., xe2x80x9cat runtime,xe2x80x9d which is in contrast to compilers that decode source code into native machine instructions prior to execution, e.g., xe2x80x9cat compile time,xe2x80x9d so that decoding is not performed during execution. Typically, the Java virtual machine implementation and support libraries, which together constitute the Java(trademark) runtime environment, will be written at least in part in a programming language other than the Java programming language (e.g., the C++ programming language).
Computer programs in the Java programming language are arranged in one or ore classes or interfaces (referred to herein jointly as classes). Such programs are generally platform, i.e., hardware and operating system, independent. As such, these computer programs may be executed, unmodified, on any computer that is able to run an implementation of the Java(trademark) runtime environment. A class written in the Java programming language is compiled to a particular binary format called the xe2x80x9cclass file formatxe2x80x9d that includes Java virtual machine instructions for the methods of a single class. In addition to the Java virtual machine instructions for the methods of a class, the class file format includes a symbol table as well as other ancillary information associated with the class.
A conceptual view of a conventional implementation of the Java runtime environment is shown in FIG. 5. As seen therein, the Java runtime environment 251 includes support libraries 253 and executable program 257 incorporating a Java virtual machine implementation 255. Support libraries 253 are also known as built-in or standard class libraries. Support libraries 253 include Java methods that may be implemented through the use of native functions. Such native functions may be delivered, in addition to Java virtual machine implementation 255, as part of executable program 257. The native functions in executable program 257 typically include functions for controlling the virtual machine and for providing platform specific functions like I/O, graphical windowing, networking, and the like. It should be appreciated that the native functions may be written in any number of different languages and are typically written in a language other than the Java programming language.
Java virtual machine implementation 255 also includes a class loader and a verifier. There is typically no clear interface between the class loader or class verifier portions of a Java virtual machine implementation and the remainder of that virtual machine implementation. Similarly, there is typically no clear interface between the native functions and the virtual machine implementation because the various components of the Java runtime environment may be designed at the same time. Accordingly, the class loader, verifier, and native functions may be written with assumptions about the Java virtual machine implementation. For example, they may be written to utilize specific data structures used within the Java virtual machine implementation. If a developer desires to change the Java virtual machine implementation, a substantial amount of time may be required to rewrite or modify the class loader, verifier, and native functions to work with the new Java virtual machine implementation.
The support libraries 253 may also include additional native functions or other methods that are at least partially dependent on the specific implementation of the Java virtual machine utilized in the Java runtime environment. For example, many operations that the support libraries perform require access to data structures managed by the Java virtual machine or services provided by the Java virtual machine (e.g., threads). In conventional implementations this significantly limits the modularity of the support libraries since any class library that includes an implementation dependent function would potentially have to be rewritten or modified to accommodate a new Java virtual machine implementation.
It view of the foregoing, it would generally be desirable to provide a modular runtime environment architecture where the functionality provided by the support libraries may be shared by multiple virtual machine implementations. It would also be desirable to provide innovative techniques of developing and delivering virtual machine implementations that would allow virtual machines to be exchanged with essentially no impact on the support libraries. Conversely, it would be desirable to facilitate the exchange of support library implementations with essentially no impact on the virtual machine implementations.
In general, embodiments of the present invention provide innovative techniques for developing and exchanging virtual machine implementations and/or support library implementations. As an example, in one embodiment of the invention, the virtual machine design specifies a set of functions for executing all or substantially all support library operations that are dependent on the implementation of the virtual machine. When a developer desires to substitute one virtual machine implementation for another, the developer is able to basically xe2x80x9cplug-inxe2x80x9d the second virtual machine implementation with minimal impact on the support libraries since both virtual machine implementations provide implementations for the set of specified functions that are dependent on the implementation of the respective virtual machine. This allows the developer great flexibility in exchanging the virtual machine implementation. Several embodiments of the invention are described below.
In one embodiment, a method for developing virtual machine implementations includes providing an interface as part of the virtual machine design that specifies functions that may be called by functions which are part of the support library implementations. The set of functions that essentially make up the interface execute all or substantially all operations utilized by the support libraries that are dependent on the implementation of the virtual machine. The set of functions may include operations that control a virtual machine implementation, access data managed by the virtual machine, and perform input/output (I/O) operations.
As the interface specifying all or substantially all of the operations utilized by the support libraries that are dependent on the implementation of the virtual machine has been specified in the design of the virtual machine, the same implementation of the support libraries may be readily utilized by any of several implementations of the virtual machine. Accordingly, one of two virtual machine implementations may be easily replaced with the other. In other words, the virtual machine implementations may be considered to be xe2x80x9cpluggable,xe2x80x9d e.g., interchangeable. In preferred embodiments, the virtual machine is a Java virtual machine and the interface is a binary interface, i.e., the virtual machine implementations are xe2x80x9cbinary pluggable.xe2x80x9d
In still another embodiment, a method for developing virtual machine implementations includes providing an interface as part of a support library design that specifies functions that may be called by functions which are part of virtual machine implementations. The set of functions that effectively make up the interface execute operations utilized by the virtual machine implementation that may be supplied by the support libraries. The set of functions may include common utilities or critical code that would preferably not be duplicated.
Since the interface specifying operations used by a virtual machine implementation that are supplied by the support libraries have been specified in the design of the support libraries, the same implementation of a virtual machine may be readily utilized by any of several implementations of the support libraries. As such, one of two support library implementations may be easily replaced with the other, i.e., the support library implementations are xe2x80x9cpluggable.xe2x80x9d In some embodiments, the support libraries are those of a Java runtime environment and the interface is a binary interface, i.e., the support library implementations are xe2x80x9cbinary pluggable.xe2x80x9d